Problem

Running two mops processes on the same project (e.g. an editor watcher and caffeine check --fix, or two back-to-back invocations from a script) intermittently failed with misleading errors:

• .mops/.check-stable/new.most: No such file or directory from mops check-stable
• EEXIST: file already exists, symlink ... from mops check/build/check-stable when [canisters.<name>.migrations] was configured

Worse, check-stable would print a "Hint: You may need a migration" suggestion (now removed in #531) that pointed users at the wrong cause entirely.

Root cause

Two scratch directories were shared across all mops processes for the same project:

1. .mops/.check-stable/ — runStableCheck did rm -rf <dir> → mkdir <dir> at the start and rm -rf <dir> at the end. Two concurrent runs would: A creates new.most, B's startup rm -rf deletes it, A's subsequent --stable-compatible read fails.
2. <parent>/.migrations-<canister>/ — prepareMigrationArgs (used when migrations need a trimmed/next-merged staging dir) wiped the dir and re-symlinked. Two concurrent runs raced on symlinkSync (EEXIST) or on each other's wipe.

Both directories existed mostly to give moc a stable path to read from during the invocation; they weren't actually shared state that needed to be coordinated.

Fix

Switch both directories to per-invocation unique paths created with fs.mkdtempSync:

• .mops/.check-stable/ → .mops/.check-stable-XXXXXX/
• <parent>/.migrations-<canister>/ → <parent>/.migrations-<canister>-XXXXXX/

Each process owns its own dir for its lifetime and removes it on exit. No shared mutable state → no race possible by construction. Existing .gitignore rules already cover both patterns (.mops/ and .migrations-*/).

Caller behavior is unchanged: prepareMigrationArgs still returns a cleanup() callback that removes the staged dir in finally.

Caveats

• A crashed process leaks its scratch dir (small — symlinks + a couple of .most/.wasm files). Both locations are gitignored, so it's cosmetic.
• Stale .mops/.check-stable/ or <parent>/.migrations-<canister>/ directories from older releases aren't auto-cleaned. They'll stay until the user removes them; harmless but visible in git status for projects that don't ignore them.

Test plan

• Added regression test: 10 parallel mops check-stable invocations against a fixture with check-limit = 3 and 4 chain migrations (forces both the check-stable scratch path and the migration staging mkdtemp branch).
• Existing migrate / check / build / check-stable suites pass (103/103, 64 snapshots).
• npm run lint + npm run check clean.
• Empirical reproduction of both error symptoms before the fix; both gone after.
• Reviewer sanity: trigger the original failure with two parallel mops check-stable (or caffeine check --fix + an editor watcher) on a project with [migrations] configured; confirm clean output.

Made with Cursor